home *** CD-ROM | disk | FTP | other *** search
/ Mac Magazin/MacEasy 32 / Mac Magazin and MacEasy Magazine CD - Issue 32.iso / Grafik & Text / OzTeX3.0 / Metafont / Help / Knuth on VFs < prev    next >
Internet Message Format  |  1996-02-26  |  41KB
  1. Date: 08 Jan 90
  2. From: Don Knuth
  3. Subject: Virtual fonts: More fun for Grand Wizards
  4.  
  5. Many writers to TeXhax during the past year or so have been struggling with
  6. interfaces between differing font conventions. For example, there's been a
  7. brisk correspondence about mixing oldstyle digits with a caps-and-small-caps
  8. alphabet. Other people despair of working with fonts supplied by manufacturers
  9. like Autologic, Compugraphic, Monotype, etc.; still others are afraid to leave
  10. the limited accent capabilities of Computer Modern for fonts containing letters
  11. that are individually accented as they should be, because such fonts are not
  12. readily available in a form that existing TeX software understands.
  13.  
  14. There is a much better way to solve such problems than the remedies
  15. that have been proposed in TeXhax. This better way was first realized
  16. by David Fuchs in 1983, when he installed it in our DVI-to-APS
  17. software at Stanford (which he also developed for commercial
  18. distribution by ArborText). We used it, for example, to typeset my
  19. article on Literate Programming for The Computer Journal, using native
  20. Autologic fonts to match the typography of that journal.
  21.  
  22. I was expecting David's strategy to become widely known and adopted.
  23. But alas --- and this has really been the only significant
  24. disappointment I've had with respect to the way TeX has been
  25. propagating around the world --- nobody else's DVI-to-X drivers have
  26. incorporated anything resembling David's ideas, and TeXhax
  27. contributors have spilled gallons of electronic ink searching for
  28. answers in the wrong direction.
  29.  
  30. The right direction is obvious once you've seen it (although it wasn't
  31. obvious in 1983): All we need is a good way to specify a mapping from
  32. TeX's notion of a font character to a device's capabilities for
  33. printing. Such a mapping was called a "virtual font" by the AMS
  34. speakers at the TUG meetings this past August. At that meeting I spoke
  35. briefly about the issue and voiced my hope that all DVI drivers be
  36. upgraded within a year to add a virtual font capability.  Dave Rodgers
  37. of ArborText announced that his company would make their WEB routines
  38. for virtual font design freely available, and I promised to edit them
  39. into a form that would match the other programs in the standard
  40. TeXware distribution.
  41.  
  42. The preparation of TeX Version 3 and MF Version 2 has taken me much longer
  43. than expected, but at last I've been able to look closely at the concept of
  44. virtual fonts. (The need for such fonts is indeed much greater now than it
  45. was before, because TeX's new multilingual capabilities are significantly
  46. more powerful only when suitable fonts are available. Virtual fonts can
  47. easily be created to meet these needs.)
  48.  
  49. After looking closely at David Fuchs's original design, I decided to design
  50. a completely new file format that would carry his ideas further, making the
  51. virtual font mechanism completely device-independent; David's original code
  52. was very APS-specific. Furthermore I decided to extend his notions so that
  53. arbitrary DVI commands (including rules and even specials) could be
  54. part of a virtual font. The new file format I've just designed is called
  55. VF; it's easy for DVI drivers to read VF files, because VF format is similar
  56. to the PK and DVI formats they already deal with.
  57.  
  58. The result is two new system routines called VFtoVP and VPtoVF. These
  59. routines are extensions of the old ones called TFtoPL and PLtoTF;
  60. there's a property-list language called VPL that extends the ordinary
  61. PL format so that virtual fonts can be created easily.
  62.  
  63. In addition to implementing these routines, I've also tested the ideas by
  64. verifying that virtual fonts could be incorporated into Tom Rokicki's dvips
  65. system without difficulty. I wrote a C program (available from Tom) that
  66. converts Adobe AFM files into virtual fonts for TeX; these virtual fonts
  67. include almost all the characteristics of Computer Modern text fonts
  68. (lacking only the uppercase Greek and the dotless j) and they include all
  69. the additional Adobe characters as well. These virtual fonts even include
  70. all the "composite characters" listed in the AFM file, from `Aacute' to
  71. `zcaron'; such characters are available as ligatures. For example, to get
  72. `Aacute' you type first `acute' (which is character 19 = ^S in Computer
  73. Modern font layout, it could also be character 194 = Meta-B if you're using an
  74. 8-bit keyboard with the new TeX) followed by `A'. Using such fonts, it's
  75. now easier for me to typeset European language texts in Times-Roman and
  76. Helvetica and Palatino than in Computer Modern! [But with less than an hour's
  77. work I could make a virtual font for Computer Modern that would do the same
  78. things; I just haven't gotten around to it yet.]
  79.  
  80. [A nice ligature scheme for dozens of European languages was just published
  81. by Haralambous in the November TUGboat. He uses only ASCII characters, getting
  82. Aacute with the combination <A. I could readily add his scheme to mine, by
  83. adding a few lines to my VPL files. Indeed, multiple conventions can be
  84. supported simultaneously (although I don't recommend that really).]
  85.  
  86. Virtual fonts make it easy to go from DVI files to the font layouts of
  87. any manufacturer or font supplier. They also (I'm sorry to say) make
  88. "track kerning" easy, for people who have to resort to that oft-abused
  89. feature of lead-free type.
  90.  
  91. Furthermore, virtual fonts solve the problem of proofreading with screen
  92. fonts or with lowres laserprinter fonts, because you can have several
  93. virtual fonts sharing a common TFM file.  Suppose, for example, that you
  94. want to typeset camera copy on an APS machine using Univers as the
  95. ultimate font, but you want to do proofreading with a screen previewer and
  96. with a laserprinter. Suppose further that you don't have Univers for your
  97. laserprinter; the closest you have is Helvetica.  And suppose that you
  98. haven't even got Helvetica for your screen, but you do have cmss10. Here's
  99. what you can do: First make a virtual property list (VPL) file
  100. univers-aps.vpl that describes the high-quality font of your ultimate
  101. output. Then edit that file into univers-laser.vpl, which has identical
  102. font metric info but maps the characters into Helvetica; similarly, make
  103. univers-screen.vpl, which maps them into cmss10. Now run VPtoVF on each of
  104. the three VPL files. This will produce three identical TFM files
  105. univers.tfm, one of which you should put on the directory read by TeX.
  106. You'll also get three distinct VF files called univers.vf, which you
  107. should put on three different directories --- one directory for your
  108. DVI-to-APS software, another for your DVI-to-laserwriter software, and the
  109. third for the DVI-to-screen previewer.  Voil^^Ra.
  110.  
  111. So virtual fonts are evidently quite virtuous. But what exactly are
  112. virtual fonts, detail-wise? Appended to this message are excerpts from
  113. VFtoVP.WEB and VPtoVF.WEB, which give a complete definition of the
  114. VF and VPL file formats.
  115.  
  116. I fully expect that all people who have implemented DVI drivers will
  117. immediately see the great potential of virtual fonts, and that they will
  118. be unable to resist installing a VF capability into their own software
  119. during the first few months of 1990. (The idea is this: For each font
  120. specified in a DVI file, the software looks first in a special table to
  121. see if the font is device-resident (in which case the TFM file is loaded,
  122. to get the character widths); failing that, it looks for a suitable GF or
  123. PK file; failing that, it looks for a VF file, which may in turn lead to
  124. other actual or virtual files. The latter files should not be loaded
  125. immediately, but only on demand, because the process is recursive.
  126. Incidentally, if no resident or GF or PK or VF file is found, a TFM file
  127. should be loaded as a last resort, so that the characters can be left
  128. blank with appropriate widths.)
  129.  
  130. %--- an excerpt from VFtoVP.web -----------------------------------------------
  131.  
  132. @* Virtual fonts.  The idea behind \.{VF} files is that a general
  133. interface mechanism is needed to switch between the myriad font
  134. layouts provided by different suppliers of typesetting equipment.
  135. Without such a mechanism, people must go to great lengths writing
  136. inscrutable macros whenever they want to use typesetting conventions
  137. based on one font layout in connection with actual fonts that have
  138. another layout. This puts an extra burden on the typesetting system,
  139. interfering with the other things it needs to do (like kerning,
  140. hyphenation, and ligature formation).
  141.  
  142. These difficulties go away when we have a ``virtual font,''
  143. i.e., a font that exists in a logical sense but not a physical sense.
  144. A typesetting system like \TeX\ can do its job without knowing where the
  145. actual characters come from; a device driver can then do its job by
  146. letting a \.{VF} file tell what actual characters correspond to the
  147. characters \TeX\ imagined were present. The actual characters
  148. can be shifted and/or magnified and/or combined with other characters
  149. from many different fonts. A virtual font can even make use of characters
  150. from virtual fonts, including itself.
  151.  
  152. Virtual fonts also allow convenient character substitutions for proofreading
  153. purposes, when fonts designed for one output device are unavailable on another.
  154.  
  155. @ A \.{VF} file is organized as a stream of 8-bit bytes, using conventions
  156. borrowed from \.{DVI} and \.{PK} files. Thus, a device driver that knows
  157. about \.{DVI} and \.{PK} format will already
  158. contain most of the mechanisms necessary to process \.{VF} files.
  159. We shall assume that \.{DVI} format is understood; the conventions in the
  160. \.{DVI} documentation (see, for example, {\sl \TeX: The Program}, part 31)
  161. are adopted here to define \.{VF} format.
  162.  
  163. A preamble
  164. appears at the beginning, followed by a sequence of character definitions,
  165. followed by a postamble. More precisely, the first byte of every \.{VF} file
  166. must be the first byte of the following ``preamble command'':
  167.  
  168. \yskip\hang|pre| 247 |i[1]| |k[1]| |x[k]| |cs[4]| |ds[4]|.
  169. Here |i| is the identification byte of \.{VF}, currently 202. The string
  170. |x| is merely a comment, usually indicating the source of the \.{VF} file.
  171. Parameters |cs| and |ds| are respectively the check sum and the design size
  172. of the virtual font; they should match the first two words in the header of
  173. the \.{TFM} file, as described below.
  174.  
  175. \yskip
  176. After the |pre| command, the preamble continues with font definitions;
  177. every font needed to specify ``actual'' characters in later
  178. \\{set\_char} commands is defined here. The font definitions are
  179. exactly the same in \.{VF} files as they are in \.{DVI} files, except
  180. that the scaled size |s| is relative and the design size |d| is absolute:
  181.  
  182. \yskip\hang|fnt_def1| 243 |k[1]| |c[4]| |s[4]| |d[4]| |a[1]| |l[1]| |n[a+l]|.
  183. Define font |k|, where |0<=k<256|.
  184.  
  185. \yskip\hang|@!fnt_def2| 244 |k[2]| |c[4]| |s[4]| |d[4]| |a[1]| |l[1]| |n[a+l]|.
  186. Define font |k|, where |0<=k<65536|.
  187.  
  188. \yskip\hang|@!fnt_def3| 245 |k[3]| |c[4]| |s[4]| |d[4]| |a[1]| |l[1]| |n[a+l]|.
  189. Define font |k|, where |0<=k<@t$2^{24}$@>|.
  190.  
  191. \yskip\hang|@!fnt_def4| 246 |k[4]| |c[4]| |s[4]| |d[4]| |a[1]| |l[1]| |n[a+l]|.
  192. Define font |k|, where |@t$-2^{31}$@><=k<@t$2^{31}$@>|.
  193.  
  194. \yskip\noindent
  195. These font numbers |k| are ``local''; they have no relation to font numbers
  196. defined in the \.{DVI} file that uses this virtual font. The dimension~|s|,
  197. which represents the scaled size of the local font being defined,
  198. is a |fix_word| relative to the design size of the virtual font.
  199. Thus if the local font is to be used at the same size
  200. as the design size of the virtual font itself, |s| will be the
  201. integer value $2^{20}$. The value of |s| must be positive and less than
  202. $2^{24}$ (thus less than 16 when considered as a |fix_word|).
  203. The dimension~|d| is a |fix_word| in units of printer's points; hence it
  204. is identical to the design size found in the corresponding \.{TFM} file.
  205.  
  206. @d id_byte=202
  207.  
  208. @<Glob...@>=
  209. @!vf_file:packed file of 0..255;
  210.  
  211. @ The preamble is followed by zero or more character packets, where each
  212. character packet begins with a byte that is $<243$. Character packets have
  213. two formats, one long and one short:
  214.  
  215. \yskip\hang|long_char| 242 |pl[4]| |cc[4]| |tfm[4]| |dvi[pl]|. This long form
  216. specifies a virtual character in the general case.
  217.  
  218. \yskip\hang|short_char0..short_char241|
  219. |pl[1]| |cc[1]| |tfm[3]| |dvi[pl]|. This short form specifies a
  220. virtual character in the common case
  221. when |0<=pl<242| and |0<=cc<256| and $0\le|tfm|<2^{24}$.
  222.  
  223.  
  224. \yskip\noindent
  225. Here |pl| denotes the packet length following the |tfm| value; |cc| is
  226. the character code; and |tfm| is the character width copied from the
  227. \.{TFM} file for this virtual font. There should be at most one character
  228. packet having any given |cc| code.
  229.  
  230. The |dvi| bytes are a sequence of complete \.{DVI} commands, properly
  231. nested with respect to |push| and |pop|. All \.{DVI} operations are
  232. permitted except |bop|, |eop|, and commands with opcodes |>=243|.
  233. Font selection commands (|fnt_num0| through |fnt4|) must refer to fonts
  234. defined in the preamble.
  235.  
  236. Dimensions that appear in the \.{DVI} instructions are analogous to
  237. |fix_word| quantities; i.e., they are integer multiples of $2^{-20}$ times
  238. the design size of the virtual font. For example, if the virtual font
  239. has design size $10\,$pt, the \.{DVI} command to move down $5\,$pt
  240. would be a \\{down} instruction with parameter $2^{19}$. The virtual font
  241. itself might be used at a different size, say $12\,$pt; then that
  242. \\{down} instruction would move down $6\,$pt instead. Each dimension
  243. must be less than $2^{24}$ in absolute value.
  244.  
  245. Device drivers processing \.{VF} files treat the sequences of |dvi| bytes
  246. as subroutines or macros, implicitly enclosing them with |push| and |pop|.
  247. Each subroutine begins with |w=x=y=z=0|, and with current font~|f| the
  248. number of the first-defined in the preamble (undefined if there's no
  249. such font). After the |dvi| commands have been
  250. performed, the |h| and~|v| position registers of \.{DVI} format are restored
  251. to their former values, and then |h| is increased by the \.{TFM} width
  252. (properly scaled)---just as if a simple character had been typeset.
  253.  
  254. @d long_char=242 {\.{VF} command for general character packet}
  255. @d set_char_0=0 {\.{DVI} command to typeset character 0 and move right}
  256. @d set1=128 {typeset a character and move right}
  257. @d set_rule=132 {typeset a rule and move right}
  258. @d put1=133 {typeset a character}
  259. @d put_rule=137 {typeset a rule}
  260. @d nop=138 {no operation}
  261. @d push=141 {save the current positions}
  262. @d pop=142 {restore previous positions}
  263. @d right1=143 {move right}
  264. @d w0=147 {move right by |w|}
  265. @d w1=148 {move right and set |w|}
  266. @d x0=152 {move right by |x|}
  267. @d x1=153 {move right and set |x|}
  268. @d down1=157 {move down}
  269. @d y0=161 {move down by |y|}
  270. @d y1=162 {move down and set |y|}
  271. @d z0=166 {move down by |z|}
  272. @d z1=167 {move down and set |z|}
  273. @d fnt_num_0=171 {set current font to 0}
  274. @d fnt1=235 {set current font}
  275. @d xxx1=239 {extension to \.{DVI} primitives}
  276. @d xxx4=242 {potentially long extension to \.{DVI} primitives}
  277. @d fnt_def1=243 {define the meaning of a font number}
  278. @d pre=247 {preamble}
  279. @d post=248 {postamble beginning}
  280. @d improper_DVI_for_VF==139,140,243,244,245,246,247,248,249,250,251,252,
  281.     253,254,255
  282.  
  283. @ The character packets are followed by a trivial postamble, consisting of
  284. one or more bytes all equal to |post| (248). The total number of bytes
  285. in the file should be a multiple of~4.
  286. %------------- and here's an extract from VPtoVF.web --------------------------
  287.  
  288. @* Property list description of font metric data.
  289. The idea behind \.{VPL} files is that precise details about fonts, i.e., the
  290. facts that are needed by typesetting routines like \TeX, sometimes have to
  291. be supplied by hand. The nested property-list format provides a reasonably
  292. convenient way to do this.
  293.  
  294. A good deal of computation is necessary to parse and process a
  295. \.{VPL} file, so it would be inappropriate for \TeX\ itself to do this
  296. every time it loads a font. \TeX\ deals only with the compact descriptions
  297. of font metric data that appear in \.{TFM} files. Such data is so compact,
  298. however, it is almost impossible for anybody but a computer to read it.
  299.  
  300. Device drivers also need a compact way to describe mappings from \TeX's idea
  301. of a font to the actual characters a device can produce. They can do this
  302. conveniently when given a packed sequence of bytes called a \.{VF} file.
  303.  
  304. The purpose of \.{VPtoVF} is to convert from a human-oriented file of text
  305. to computer-oriented files of binary numbers. There's a companion program,
  306. \.{VFtoVP}, which goes the other way.
  307.  
  308. @<Glob...@>=
  309. @!vpl_file:text;
  310.  
  311. @ @<Set init...@>=
  312. reset(vpl_file);
  313.  
  314. @ A \.{VPL} file is like a \.{PL} file with a few extra features, so we
  315. can begin to define it by reviewing the definition of \.{PL} files. The
  316. material in the next few sections is copied from the program \.{PLtoTF}.
  317.  
  318. A \.{PL} file is a list of entries of the form
  319. $$\.{(PROPERTYNAME VALUE)}$$
  320. where the property name is one of a finite set of names understood by
  321. this program, and the value may itself in turn be a property list.
  322. The idea is best understood by looking at an example, so let's consider
  323. a fragment of the \.{PL} file for a hypothetical font.
  324. $$\vbox{\halign{\.{#}\hfil\cr
  325. (FAMILY NOVA)\cr
  326. (FACE F MIE)\cr
  327. (CODINGSCHEME ASCII)\cr
  328. (DESIGNSIZE D 10)\cr
  329. (DESIGNUNITS D 18)\cr
  330. (COMMENT A COMMENT IS IGNORED)\cr
  331. (COMMENT (EXCEPT THIS ONE ISN'T))\cr
  332. (COMMENT (ACTUALLY IT IS, EVEN THOUGH\cr
  333. \qquad\qquad IT SAYS IT ISN'T))\cr
  334. (FONTDIMEN\cr
  335. \qquad   (SLANT R -.25)\cr
  336. \qquad   (SPACE D 6)\cr
  337. \qquad   (SHRINK D 2)\cr
  338. \qquad   (STRETCH D 3)\cr
  339. \qquad   (XHEIGHT R 10.55)\cr
  340. \qquad   (QUAD D 18)\cr
  341. \qquad   )\cr
  342. (LIGTABLE\cr
  343. \qquad   (LABEL C f)\cr
  344. \qquad   (LIG C f O 200)\cr
  345. \qquad   (SKIP D 1)\cr
  346. \qquad   (LABEL O 200)\cr
  347. \qquad   (LIG C i O 201)\cr
  348. \qquad   (KRN O 51 R 1.5)\cr
  349. \qquad   (/LIG C ? C f)\cr
  350. \qquad   (STOP)\cr
  351. \qquad   )\cr
  352. (CHARACTER C f\cr
  353. \qquad   (CHARWD D 6)\cr
  354. \qquad   (CHARHT R 13.5)\cr
  355. \qquad   (CHARIC R 1.5)\cr
  356. \qquad   )\cr}}$$
  357. This example says that the font whose metric information is being described
  358. belongs to the hypothetical
  359. \.{NOVA} family; its face code is medium italic extended;
  360. and the characters appear in ASCII code positions. The design size is 10
  361. points, and all other sizes in this \.{PL} file are given in units such that
  362. 18 units
  363. equals the design size. The font is slanted with a slope of $-.25$ (hence the
  364. letters actually slant backward---perhaps that is why the family name is
  365. \.{NOVA}). The normal space between words is 6 units (i.e., one third of
  366. the 18-unit design size), with glue that shrinks by 2 units or stretches by 3.
  367. The letters for which accents don't need to be raised or lowered are 10.55
  368. units high, and one em equals 18 units.
  369.  
  370. The example ligature table is a bit trickier. It specifies that the
  371. letter \.f followed by another \.f is changed to code @'200, while
  372. code @'200 followed by \.i is changed to @'201; presumably codes @'200
  373. and @'201 represent the ligatures `ff' and `ffi'.  Moreover, in both cases
  374. \.f and @'200, if the following character is the code @'51 (which is a
  375. right parenthesis), an additional 1.5 units of space should be inserted
  376. before the @'51.  (The `\.{SKIP}~\.D~\.1' skips over one \.{LIG} or
  377. \.{KRN} command, which in this case is the second \.{LIG}; in this way
  378. two different ligature/kern programs can come together.)
  379. Finally, if either \.f or @'200 is followed by a question mark,
  380. the question mark is replaced by \.f and the ligature program is
  381. started over. (Thus, the character pair `\.{f?}' would actually become
  382. the ligature `ff', and `\.{ff?}' or `\.{f?f}' would become `fff'. To
  383. avoid this restart procedure, the \.{/LIG} command could be replaced
  384. by \.{/LIG>}; then `\.{f?} would become `f\kern0ptf' and `\.{f?f}'
  385. would become `f\kern0ptff'.)
  386.  
  387. Character \.f itself is 6 units wide and 13.5 units tall, in this example.
  388. Its depth is zero (since \.{CHARDP} is not given), and its italic correction
  389. is 1.5 units.
  390.  
  391. @ The example above illustrates most of the features found in \.{PL} files.
  392. Note that some property names, like \.{FAMILY} or \.{COMMENT}, take a
  393. string as their value; this string continues until the first unmatched
  394. right parenthesis. But most property names, like \.{DESIGNSIZE} and \.{SLANT}
  395. and \.{LABEL}, take a number as their value. This number can be expressed in
  396. a variety of ways, indicated by a prefixed code; \.D stands for decimal,
  397. \.H for hexadecimal, \.O for octal, \.R for real, \.C for character, and
  398. \.F for ``face.''  Other property names, like \.{LIG}, take two numbers as
  399. their value.  And still other names, like \.{FONTDIMEN} and \.{LIGTABLE} and
  400. \.{CHARACTER}, have more complicated values that involve property lists.
  401.  
  402. A property name is supposed to be used only in an appropriate property
  403. list.  For example, \.{CHARWD} shouldn't occur on the outer level or
  404. within \.{FONTDIMEN}.
  405.  
  406. The individual property-and-value pairs in a property list can appear in
  407. any order. For instance, `\.{SHRINK}' precedes `\.{STRETCH}' in the above
  408. example, although the \.{TFM} file always puts the stretch parameter first.
  409. One could even give the information about characters like `\.f' before
  410. specifying the number of units in the design size, or before specifying the
  411. ligature and kerning table. However, the \.{LIGTABLE} itself is an exception
  412. to this rule; the individual elements of the \.{LIGTABLE} property list
  413. can be reordered only to a certain extent without changing the meaning
  414. of that table.
  415.  
  416. If property-and-value pairs are omitted, a default value is used. For example,
  417. we have already noted that the default for \.{CHARDP} is zero. The default
  418. for {\sl every\/} numeric value is, in fact, zero, unless otherwise stated
  419. below.
  420.  
  421. If the same property name is used more than once, \.{VPtoVF} will not notice
  422. the discrepancy; it simply uses the final value given. Once again, however, the
  423. \.{LIGTABLE} is an exception to this rule; \.{VPtoVF} will complain if there
  424. is more than one label for some character. And of course many of the
  425. entries in the \.{LIGTABLE} property list have the same property name.
  426.  
  427. @ A \.{VPL} file also includes information about how to create each character,
  428. by typesetting characters from other fonts and/or by drawing lines, etc.
  429. Such information is the value of the `\.{MAP}' property, which can be
  430. illustrated as follows:
  431. $$\vbox{\halign{\.{#}\hfil\cr
  432. (MAPFONT D 0 (FONTNAME Times-Roman))\cr
  433. (MAPFONT D 1 (FONTNAME Symbol))\cr
  434. (MAPFONT D 2 (FONTNAME cmr10)(FONTAT D 20))\cr
  435. (CHARACTER O 0 (MAP (SELECTFONT D 1)(SETCHAR C G)))\cr
  436. (CHARACTER O 76 (MAP (SETCHAR O 277)))\cr
  437. (CHARACTER D 197 (MAP\cr
  438. \qquad(PUSH)(SETCHAR C A)(POP)\cr
  439. \qquad(MOVEUP R 0.937)(MOVERIGHT R 1.5)(SETCHAR O 312)))\cr
  440. (CHARACTER O 200 (MAP (MOVEDOWN R 2.1)(SETRULE R 1 R 8)))\cr
  441. (CHARACTER O 201 (MAP\cr
  442. \qquad (SPECIAL ps: /SaveGray currentgray def .5 setgray)\cr
  443. \qquad (SELECTFONT D 2)(SETCHAR C A)\cr
  444. \qquad (SPECIAL SaveGray setgray)))\cr
  445. }}$$
  446. (These specifications appear in addition to the conventional \.{PL}
  447. information. The \.{MAP} attribute can be mixed in with other attributes
  448. like \.{CHARWD} or it can be given separately.)
  449.  
  450. In this example, the virtual font is composed of characters that can be
  451. fabricated from three actual fonts, `\.{Times-Roman}',
  452. `\.{Symbol}', and `\.{cmr10} \.{at} \.{20\\u}' (where \.{\\u}
  453. is the unit size in this \.{VPL} file). Character |@'0| is typeset as
  454. a `G' from the symbol font. Character |@'76| is typeset as character |@'277|
  455. from the ordinary Times font. (If no other font is selected, font
  456. number~0 is the default. If no \.{MAP} attribute is given, the default map
  457. is a character of the same number in the default font.)
  458.  
  459. Character 197 (decimal) is more interesting: First an A is typeset (in the
  460. default font Times), and this is enclosed by \.{PUSH} and \.{POP} so that
  461. the original position is restored. Then the accent character |@'312| is
  462. typeset, after moving up .937 units and right 1.5 units.
  463.  
  464. To typeset character |@'200| in this virtual font, we move down 2.1 units,
  465. then typeset a rule that is 1 unit high and 8 units wide.
  466.  
  467. Finally, to typeset character |@'201|, we do something that requires a
  468. special ability to interpret PostScript commands; this example
  469. sets the PostScript ``color'' to 50\char`\%\ gray and typesets an `A'
  470. from \.{cmr10} in that color.
  471.  
  472. In general, the \.{MAP} attribute of a virtual character can be any sequence
  473. of typesetting commands that might appear in a page of a \.{DVI} file.
  474. A single character might map into an entire page.
  475.  
  476. @ But instead of relying on a hypothetical example, let's consider a complete
  477. grammar for \.{VPL} files, beginning with the (unchanged) grammatical rules
  478. for \.{PL} files. At the outer level, the following property names
  479. are valid in any \.{PL} file:
  480.  
  481. \yskip\hang\.{CHECKSUM} (four-byte value). The value, which should be a
  482. nonnegative integer less than $2^{32}$, is used to identify a particular
  483. version of a font; it should match the check sum value stored with the font
  484. itself. An explicit check sum of zero is used to bypass
  485. check sum testing. If no checksum is specified in the \.{VPL} file,
  486. \.{VPtoVF} will compute the checksum that \MF\ would compute from the
  487. same data.
  488.  
  489.  
  490. \yskip\hang\.{DESIGNSIZE} (numeric value, default is 10). The value, which
  491. should be a real number in the range |1.0<=x<2048|, represents the default
  492. amount by which all quantities will be scaled if the font is not loaded
  493. with an `\.{at}' specification. For example, if one says
  494. `\.{\\font\\A=cmr10 at 15pt}' in \TeX\ language, the design size in the \.{TFM}
  495. file is ignored and effectively replaced by 15 points; but if one simply
  496. says `\.{\\font\\A=cmr10}' the stated design size is used. This quantity is
  497. always in units of printer's points.
  498.  
  499. \yskip\hang\.{DESIGNUNITS} (numeric value, default is 1). The value
  500. should be a positive real number; it says how many units equals the design
  501. size (or the eventual `\.{at}' size, if the font is being scaled). For
  502. example, suppose you have a font that has been digitized with 600 pixels per
  503. em, and the design size is one em; then you could say `\.{(DESIGNUNITS R 600)}'
  504. if you wanted to give all of your measurements in units of pixels.
  505.  
  506. \yskip\hang\.{CODINGSCHEME} (string value, default is `\.{UNSPECIFIED}').
  507. The string should not contain parentheses, and its length must be less than 40.
  508. It identifies the correspondence between the numeric codes and font characters.
  509. (\TeX\ ignores this information, but other software programs make use of it.)
  510.  
  511. \yskip\hang\.{FAMILY} (string value, default is `\.{UNSPECIFIED}').
  512. The string should not contain parentheses, and its length must be less than 20.
  513. It identifies the name of the family to which this font belongs, e.g.,
  514. `\.{HELVETICA}'.  (\TeX\ ignores this information; but it is needed, for
  515. example, when converting \.{DVI} files to \.{PRESS} files for Xerox
  516. equipment.)
  517.  
  518. \yskip\hang\.{FACE} (one-byte value). This number, which must lie
  519. between 0 and 255 inclusive, is a subsidiary ident\-ifi\-ca\-tion of
  520. the font within its family. For example, bold italic condensed fonts
  521. might have the same family name as light roman extended fonts,
  522. differing only in their face byte.  (\TeX\ ignores this information;
  523. but it is needed, for example, when converting \.{DVI} files to
  524. \.{PRESS} files for Xerox equipment.)
  525.  
  526. \yskip\hang\.{SEVENBITSAFEFLAG} (string value, default is
  527. `\.{FALSE}'). The value should start with either `\.T' (true) or `\.F'
  528. (false). If true, character codes less than 128 cannot lead to codes
  529. of 128 or more via ligatures or charlists or extensible characters.
  530. (\TeX82 ignores this flag, but older versions of \TeX\ would only
  531. accept \.{TFM} files that were seven-bit safe.)  \.{VPtoVF} computes
  532. the correct value of this flag and gives an error message only if a
  533. claimed ``true'' value is incorrect.
  534.  
  535. \yskip\hang\.{HEADER} (a one-byte value followed by a four-byte value).
  536. The one-byte value should be between 18 and a maximum limit that can be
  537. raised or lowered depending on the compile-time setting of |max_header_bytes|.
  538. The four-byte value goes into the header word whose index is the one-byte
  539. value; for example, to set |header[18]:=1|, one may write
  540. `\.{(HEADER D 18 O 1)}'. This notation is used for header information that
  541. is presently unnamed. (\TeX\ ignores it.)
  542.  
  543. \yskip\hang\.{FONTDIMEN} (property list value). See below for the names
  544. allowed in this property list.
  545.  
  546. \yskip\hang\.{LIGTABLE} (property list value). See below for the rules
  547. about this special kind of property list.
  548.  
  549. \yskip\hang\.{BOUNDARYCHAR} (one-byte value). If this character appears in
  550. a \.{LIGTABLE} command, it matches ``end of word'' as well as itself.
  551. If no boundary character is given and no \.{LABEL} \.{BOUNDARYCHAR} occurs
  552. within \.{LIGTABLE}, word boundaries will not affect ligatures or kerning.
  553.  
  554. \yskip\hang\.{CHARACTER}. The value is a one-byte integer followed by
  555. a property list. The integer represents the number of a character that is
  556. present in the font; the property list of a character is defined below.
  557. The default is an empty property list.
  558.  
  559. @ Numeric property list values can be given in various forms identified by
  560. a prefixed letter.
  561.  
  562. \yskip\hang\.C denotes an ASCII character, which should be a standard visible
  563. character that is not a parenthesis. The numeric value will therefore be
  564. between @'41 and @'176 but not @'50 or @'51.
  565.  
  566. \yskip\hang\.D denotes an unsigned decimal integer, which must be
  567. less than $2^{32}$, i.e., at most `\.{D 4294967295}'.
  568.  
  569. \yskip\hang\.F denotes a three-letter Xerox face code; the admissible codes
  570. are \.{MRR}, \.{MIR}, \.{BRR}, \.{BIR}, \.{LRR}, \.{LIR}, \.{MRC}, \.{MIC},
  571. \.{BRC}, \.{BIC}, \.{LRC}, \.{LIC}, \.{MRE}, \.{MIE}, \.{BRE}, \.{BIE},
  572. \.{LRE}, and \.{LIE}, denoting the integers 0 to 17, respectively.
  573.  
  574. \yskip\hang\.O denotes an unsigned octal integer, which must be less than
  575. $2^{32}$, i.e., at most `\.{O 37777777777}'.
  576.  
  577. \yskip\hang\.H denotes an unsigned hexadecimal integer, which must be less than
  578. $2^{32}$, i.e., at most `\.{H FFFFFFFF}'.
  579.  
  580. \yskip\hang\.R denotes a real number in decimal notation, optionally preceded
  581. by a `\.+' or `\.-' sign, and optionally including a decimal point. The
  582. absolute value must be less than 2048.
  583.  
  584. @ The property names allowed in a \.{FONTDIMEN} property list correspond to
  585. various \TeX\ parameters, each of which has a (real) numeric value. All
  586. of the parameters except \.{SLANT} are in design units. The admissible
  587. names are \.{SLANT}, \.{SPACE}, \.{STRETCH}, \.{SHRINK}, \.{XHEIGHT},
  588. \.{QUAD}, \.{EXTRASPACE}, \.{NUM1}, \.{NUM2}, \.{NUM3}, \.{DENOM1},
  589. \.{DENOM2}, \.{SUP1}, \.{SUP2}, \.{SUP3}, \.{SUB1}, \.{SUB2}, \.{SUPDROP},
  590. \.{SUBDROP}, \.{DELIM1}, \.{DELIM2}, and \.{AXISHEIGHT}, for parameters
  591. 1~to~22. The alternate names \.{DEFAULTRULETHICKNESS},
  592. \.{BIGOPSPACING1}, \.{BIGOPSPACING2}, \.{BIGOPSPACING3},
  593. \.{BIGOPSPACING4}, and \.{BIGOPSPACING5}, may also be used for parameters
  594. 8 to 13.
  595.  
  596. The notation `\.{PARAMETER} $n$' provides another way to specify the
  597. $n$th parameter; for example, `\.{(PARAMETER} \.{D 1 R -.25)}' is another way
  598. to specify that the \.{SLANT} is $-0.25$. The value of $n$ must be positive
  599. and less than |max_param_words|.
  600.  
  601. @ The elements of a \.{CHARACTER} property list can be of six different types.
  602.  
  603. \yskip\hang\.{CHARWD} (real value) denotes the character's width in
  604. design units.
  605.  
  606. \yskip\hang\.{CHARHT} (real value) denotes the character's height in
  607. design units.
  608.  
  609. \yskip\hang\.{CHARDP} (real value) denotes the character's depth in
  610. design units.
  611.  
  612. \yskip\hang\.{CHARIC} (real value) denotes the character's italic correction in
  613. design units.
  614.  
  615. \yskip\hang\.{NEXTLARGER} (one-byte value), specifies the character that
  616. follows the present one in a ``charlist.'' The value must be the number of a
  617. character in the font, and there must be no infinite cycles of supposedly
  618. larger and larger characters.
  619.  
  620. \yskip\hang\.{VARCHAR} (property list value), specifies an extensible
  621. character.  This option and \.{NEXTLARGER} are mutually exclusive;
  622. i.e., they cannot both be used within the same \.{CHARACTER} list.
  623.  
  624. \yskip\noindent
  625. The elements of a \.{VARCHAR} property list are either \.{TOP}, \.{MID},
  626. \.{BOT} or \.{REP}; the values are integers, which must be zero or the number
  627. or a character in the font. A zero value for \.{TOP}, \.{MID}, or \.{BOT} means
  628. that the corresponding piece of the extensible character is absent. A nonzero
  629. value, or a \.{REP} value of zero, denotes the character code used to make
  630. up the top, middle, bottom, or replicated piece of an extensible character.
  631.   
  632. @ A \.{LIGTABLE} property list contains elements of four kinds, specifying a
  633. program in a simple command language that \TeX\ uses for ligatures and kerns.
  634. If several \.{LIGTABLE} lists appear, they are effectively concatenated into
  635. a single list.
  636.  
  637. \yskip\hang\.{LABEL} (one-byte value) means that the program for the
  638. stated character value starts here. The integer must be the number of a
  639. character in the font; its \.{CHARACTER} property list must not have a
  640. \.{NEXTLARGER} or \.{VARCHAR} field. At least one \.{LIG} or \.{KRN} step
  641. must follow.
  642.  
  643. \yskip\hang\.{LABEL} \.{BOUNDARYCHAR} means that the program for
  644. beginning-of-word ligatures starts here.
  645.  
  646. \yskip\hang\.{LIG} (two one-byte values). The instruction `\.{(LIG} $c$ $r$\.)'
  647. means, ``If the next character is $c$, then insert character~$r$ and
  648. possibly delete the current character and/or~$c$;
  649. otherwise go on to the next instruction.''
  650. Characters $r$ and $c$ must be present in the font. \.{LIG} may be immediately
  651. preceded or followed by a slash, and then immediately followed by \.>
  652. characters not exceeding the number of slashes. Thus there are eight
  653. possible forms:
  654. $$\hbox to .8\hsize{\.{LIG}\hfil\.{/LIG}\hfil\.{/LIG>}\hfil
  655. \.{LIG/}\hfil\.{LIG/>}\hfil\.{/LIG/}\hfil\.{/LIG/>}\hfil\.{/LIG/>>}}$$
  656. The slashes specify retention of the left or right original character; the
  657. \.> signs specify passing over the result without further ligature processing.
  658.  
  659. \yskip\hang\.{KRN} (a one-byte value and a real value). The instruction
  660. `\.{(KRN} $c$ $r$\.)' means, ``If the next character is $c$, then insert
  661. a blank space of width $r$ between the current character character and $c$;
  662. otherwise go on to the next intruction.'' The value of $r$, which is in
  663. units of the design size, is often negative. Character code $c$ must exist
  664. in the font.
  665.  
  666. \yskip\hang\.{STOP} (no value). This instruction ends a ligature/kern program.
  667. It must follow either a \.{LIG} or \.{KRN} instruction, not a \.{LABEL}
  668. or \.{STOP} or \.{SKIP}.
  669.  
  670. \yskip\hang\.{SKIP} (value in the range |0..127|). This instruction specifies
  671. continuation of a ligature/kern program after the specified number of \.{LIG}
  672. or \.{KRN} has been skipped over. The number of subsequent \.{LIG} and \.{KRN}
  673. instructions must therefore exceed this specified amount.
  674.  
  675. @ In addition to all these possibilities, the property name \.{COMMENT} is
  676. allowed in any property list. Such comments are ignored.
  677.  
  678. @ So that is what \.{PL} files hold. In a \.{VPL} file additional
  679. properties are recognized; two of these are valid on the outermost level:
  680.  
  681. \yskip\hang\.{VTITLE} (string value, default is empty). The value will be
  682. reproduced at the beginning of the \.{VF} file (and printed on the terminal
  683. by \.{VFtoVP} when it examines that file).
  684.  
  685. \yskip\hang\.{MAPFONT}. The value is a nonnegative integer followed by
  686. a property list. The integer represents an identifying number for fonts
  687. used in \.{MAP} attributes. The property list, which identifies the font and
  688. relative size, is defined below.
  689.  
  690. \yskip\noindent
  691. And one additional ``virtual property'' is valid within a \.{CHARACTER}:
  692.  
  693. \yskip\hang\.{MAP}. The value is a property list consisting of typesetting
  694. commands. Default is the single command \.{SETCHAR}~$c$, where $c$ is
  695. the current character number.
  696.  
  697. @ The elements of a \.{MAPFONT} property list can be of the following types.
  698.  
  699. \yskip\hang\.{FONTNAME} (string value, default is \.{NULL}).
  700. This is the font's identifying name.
  701.  
  702. \yskip\hang\.{FONTAREA} (string value, default is empty). If the font appears
  703. in a nonstandard directory, according to local conventions, the directory
  704. name is given here. (This is system dependent, just as in \.{DVI} files.)
  705.  
  706. \yskip\hang\.{FONTCHECKSUM} (four-byte value, default is zero). This value,
  707. which should be a nonnegative integer less than $2^{32}$, can be used to
  708. check that the font being referred to matches the intended font. If nonzero,
  709. it should equal the \.{CHECKSUM} parameter in that font.
  710.  
  711. \yskip\hang\.{FONTAT} (numeric value, default is the \.{DESIGNUNITS} of the
  712. present virtual font). This value is relative to the design units of
  713. the present virtual font, hence it will be scaled when the virtual
  714. font is magnified or reduced.  It represents the value that will
  715. effectively replace the design size of the font being referred to,
  716. so that all characters will be scaled appropriately.
  717.  
  718. \yskip\hang\.{FONTDSIZE} (numeric value, default is 10). This value is
  719. absolute, in units of printer's points. It should equal the \.{DESIGNSIZE}
  720. parameter in the font being referred to.
  721.  
  722. \yskip\noindent
  723. If any of the
  724. string values contain parentheses, the parentheses must be balanced. Leading
  725. blanks are removed from the strings, but trailing blanks are not.
  726.  
  727. @ Finally, the elements of a \.{MAP} property list are an ordered sequence
  728. of typesetting commands chosen from among the following:
  729.  
  730. \yskip\hang\.{SELECTFONT} (four-byte integer value). The value must be the
  731. number of a previously defined \.{MAPFONT}. This font (or more precisely, the
  732. final font that is mapped to that code number, if two \.{MAPFONT} properties
  733. happen to specify the same code) will be used in subsequent \.{SETCHAR}
  734. instructions until overridden by another \.{SELECTFONT}. The first-specified
  735. \.{MAPFONT} is implicitly selected before the first \.{SELECTFONT} in every
  736. character's map.
  737.  
  738. \yskip\hang\.{SETCHAR} (one-byte integer value). There must be a character of
  739. this number in the currently selected font. (\.{VPtoVF} doesn't check that
  740. the character is valid, but \.{VFtoVP} does.) That character is typeset at the
  741. current position, and the typesetter moves right by the \.{CHARWD} in
  742. that character's \.{TFM} file.
  743.  
  744. \yskip\hang\.{SETRULE} (two real values). The first value specifies height,
  745. the second specifies width, in design units. If both height and width are
  746. positive, a rule is typeset at the current position. Then the typesetter
  747. moves right, by the specified width.
  748.  
  749. \yskip\hang\.{MOVERIGHT}, \.{MOVELEFT}, \.{MOVEUP}, \.{MOVEDOWN} (real
  750. value). The typesetter moves its current position
  751. by the number of design units specified.
  752.  
  753. \yskip\hang\.{PUSH} The current typesetter position is remembered, to
  754. be restored on a subsequent \.{POP}.
  755.  
  756. \yskip\hang\.{POP} The current typesetter position is reset to where it
  757. was on the most recent unmatched \.{PUSH}. The \.{PUSH} and \.{POP}
  758. commands in any \.{MAP} must be properly nested like balanced parentheses.
  759.  
  760. \yskip\hang\.{SPECIAL} (string value). The subsequent characters, starting
  761. with the first nonblank and ending just before the first `\.)' that has no
  762. matching `\.(', are interpreted according to local conventions with the
  763. same system-dependent meaning as a `special' (\\{xxx}) command
  764. in a \.{DVI} file.
  765.  
  766. \yskip\hang\.{SPECIALHEX} (hexadecimal string value). The subsequent
  767. nonblank characters before the next `\.)' must consist entirely of
  768. hexadecimal digits, and they must contain an even number of such digits.
  769. Each pair of hex digits specifies a byte, and this string of bytes is
  770. treated just as the value of a \.{SPECIAL}. (This convention permits
  771. arbitrary byte strings to be represented in an ordinary text file.)
  772.  
  773. @ Virtual font mapping is a recursive process, like macro expansion.
  774. Thus, a \.{MAPFONT} might
  775. specify another virtual font, whose characters are themselves mapped to
  776. other fonts. As an example of this possibility, consider the
  777. following curious file called \.{recurse.vpl}, which defines a
  778. virtual font that is self-contained and self-referential:
  779. $$\vbox{\halign{\.{#}\cr
  780. (VTITLE Example of recursion)\cr
  781. (MAPFONT D 0 (FONTNAME recurse)(FONTAT D 2))\cr
  782. (CHARACTER C A (CHARWD D 1)(CHARHT D 1)(MAP (SETRULE D 1 D 1)))\cr
  783. (CHARACTER C B (CHARWD D 2)(CHARHT D 2)(MAP (SETCHAR C A)))\cr
  784. (CHARACTER C C (CHARWD D 4)(CHARHT D 4)(MAP (SETCHAR C B)))\cr
  785. }}$$
  786. The design size is 10 points (the default), hence the character \.A
  787. in font \.{recurse} is a $10\times10$ point black square. Character \.B
  788. is typeset as character \.A in \.{recurse} {scaled} {2000}, hence it
  789. is a $20\times20$ point black square. And character \.C is typeset as
  790. character \.{B} in \.{recurse} {scaled} {2000}, hence its size is
  791. $40\times40$.
  792.  
  793. Users are responsible for making sure that infinite recursion doesn't happen.
  794.